KERNEL=="sda2", ENV UDISKS_PRESENTATION_HIDE ="1" This is not valid anymore in udisks2, but only the property name has changed. You can simply replace by:
KERNEL=="sda2", ENV UDISKS_IGNORE ="1"
corsac@scapa: umask 066 corsac@scapa: gpg -o 71ef0ba8.gpg --export-secret-keys 71ef0ba8
corsac@scapa: gpg --expert --edit-key 71ef0ba8 gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection? 8 Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? e Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? Q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 1y Key expires at dim. 27 oct. 2013 20:38:44 CET Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.Repeat this for encryption and authentication subkeys. Then save and send the key to keyservers
gpg> save corsac@scapa: gpg --send-keys 71ef0ba8
root@scapa: ~# apt-get install pcscd scdaemonPlug the reader, insert the card, make sure it's detected:
corsac@scapa: gpg --card-status Application ID ...: D2760001240102000005000016A10000 Version ..........: 2.0 Manufacturer .....: ZeitControl ...You can edit various parameter (name etc.) and change the PINs using gpg:
corsac@scapa: gpg --change-pin corsac@scapa: gpg --card-edit
corsac@scapa: gpg -o 71ef0ba8.gpg --export-secret-keys 71ef0ba8
corsac@scapa: gpg --edit-key 71ef0ba8 gpg> key 1 # select encryption subkey gpg> keytocard gpg> key 2 # select signature subkey gpg> keytocard gpg> key 3 # select authentication subkey gpg> keytocard gpg> saveA quick check on the card now reveals that it's populated:
corsac@scapa: gpg --card-status Application ID ...: D2760001240102000005000016A10000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 000016A1 Name of cardholder: Yves-Alexis Perez Language prefs ...: fr Sex ..............: unspecified URL of public key : http://www.corsac.net/71ef0ba8.asc Login data .......: corsac Signature PIN ....: forced Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 3 3 Signature counter : 7 Signature key ....: 9745 B022 7323 81FE 9E7E AFF5 6DDB 53F2 A675 C0A5 created ....: 2012-10-27 11:24:07 Encryption key....: F7E0 078F EA1A 5F23 92E0 20B3 A83A D136 D98D 0D9F created ....: 2012-10-27 11:27:01 Authentication key: 8CFD D478 AB4A 16F8 F0EC CD33 24E2 3B5C CC0E 273D created ....: 2012-10-17 14:29:18 General key info..: pub 2048R/A675C0A5 2012-10-27 Yves-Alexis Perez sec> 4096R/71EF0BA8 created: 2009-05-06 expires: never card-no: 0005 000016A2 ssb 4096g/36E31BD8 created: 2009-05-06 expires: never ssb> 2048R/CC0E273D created: 2012-10-17 expires: 2013-10-27 card-no: 0005 000016A1 ssb> 2048R/A675C0A5 created: 2012-10-27 expires: 2013-10-27 card-no: 0005 000016A1 ssb> 2048R/D98D0D9F created: 2012-10-27 expires: 2013-10-27 card-no: 0005 000016A1
corsac@scapa: gpg -o 71ef0ba8-subkeys.gpg --export-secret-subkeys 71ef0ba8Note that only the subkeys private parts have been moved to the card, not the primary one, so you're still able to sign keys. Here, you have multiple choices. You can simply erase the private key (and later re-import the stubs) and use the offline copy made above when you need to sign another key.
corsac@scapa: ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EA... cardno:0005000016A1
And now you can add it to your various authorized_keys
and use the smartcard for SSH.
Howdy, -desktop,
Hopefully we can contain the flame to the other thread.
desktop-base/7.0.0~exp2 has been accepted into experimental, for testing
by y'all (and generally interested folks) for feedback and testing
before pushing to unstable.
I urge y'all to give it a try and provide feedback on issues that you
may run into.
You can overlay experimental on any unstable install, and install
desktop-base by running:
$ sudo apt-get -t experimental install desktop-base
For more information on using experimental, check out the wiki[1].
If you would care to test out the plymouth bootsplash, here's the short
version of how to get it running:
1) Install plymouth via apt ($ sudo apt-get install plymouth)
2) Set the theme to use joy' ($ sudo /usr/sbin/plymouth-set-default-theme joy)
3) Edit the file /etc/default/grub, and add
"splash" to GRUB_CMDLINE_LINUX_DEFAULT
4) update your initramfs ($ sudo update-initramfs -u)
Here's the full list of changes from the version in unstable:
desktop-base (7.0.0~exp2) experimental; urgency=low
* Remove GConf defaults, they are not used anymore.
* Remove the GDM3 settings, since the configuration format for GDM
change again, yay.
* Add a dconf file for the new-style GDM3 configuration.
* Add a XML file describing the available resolutions for the
background (for use with GNOME).
* postinst: use a higher priority for the 1920x1080 background.
* Cleanup postinst/prerm/postrm.
* Add a new alternative: desktop-background.xml.
* Use it from the gsettings override.
* Reload gdm3 after installation/removal.
* Drop old libgnome2-common hack.
* Clean up an alternative that is no longer available.
-- Josselin Mouette <joss@debian.org> Sat, 23 Jun 2012 23:28:15 +0200
desktop-base (7.0.0~exp1) experimental; urgency=low
[ Paul Tagliamonte ]
* Adding myself as a maintainer
* We've got a new theme -- joy' by Adrien Aubourg. Thanks, Adrien!
- Theme added to backgrounds.
- Theme added for Grub
- Background changed for GDM3
- Theme added for KDM & changed that to default.
- Theme added for ksplash & changed to default.
* Standards bump to 3.9.3
* Pre-Dependency added for dpkg (>= 1.15.7.2~), since we use dpkg helpers
in our preinst.
* Add in Jonathan Carter's Plymouth theme.
[ Jonathan Carter ]
* Remove splashy theme since it's no longer available in archives
[ Yves-Alexis Perez ]
* Install emblem in the correct folder.
-- Paul Tagliamonte <paultag@ubuntu.com> Sat, 23 Jun 2012 13:00:47 +0200
I thank all of you dearly for putting up with this,
Paul
[1]: http://wiki.debian.org/DebianExperimental
master:/srv/leader/news/bits-from-the-DPL.*
deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/ The repository is signed by my key which you can add to your apt setup using apt-key add. If you want to rebuild the packages yourself, here's the method:
mkdir kernel-grsec
cd kernel-grsec
svn checkout
svn://svn.debian.org/svn/kernel/dists/sid/linux-2.6
git clone
git://anonscm.debian.org/users/corsac/grsec-patches.git
wget
http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.bz2
wget
http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.bz2.sign
gpg --verify linux-3.0.tar.bz2
cd linux-2.6
apt-get build-dep linux-2.6
export QUILT_PATCHES=../grsec-patches
quilt push -a
python debian/bin/genorig.py ../linux-3.0.tar.bz2
debian/rules orig
fakeroot debian/rules source
fakeroot make -f debian/rules.gen binary-arch_amd64_grsec_amd64
You could also do dpkg-buildpackage, pdebuild or whatever.
Kernel
handbook is a nice reading too if you want more information on
how to rebuild Debian kernels. The quilt push -a may fail if you
checkout an svn version more recent than mine. I try to keep
patches up to date but I usually have some delay.
Note that installing the kernel will require installing
linux-grsec-base package. Binary is not yet available on my mirror
but you can easily build it. Source can be found on
git.debian.org.
If you're interested by this, don't hesitate to mail me or the
bug.
modprobe -r e1000e
modprobe e1000e
to see if it fixed the problem, but it didn't. Worse, the
interface disappeared and never reappeared. I tried to reboot but
it didn't fix the problem, the link was still down. Running really
late, I put the file on a usb key and printed it from the powerbook
and postponed the fix for later.
Now, this evening, I tried to investigate a bit more. Symptoms
weren't only that the nic wasn't working, but there was a high load
on the system (1-2 at idle), unresponsiveness every second or so,
and watching top I could see spikes of high cpu usage for the
kworker kernel thread. Typing that on google you can find a lot of
people running on this issue, usually starting around kernel 2.6.36
or 2.6.37. Now, I might have upgraded the kernel recently to
3.0.0-4, but that didn't look related since the problem first
appeared when the laptop was up and running. And I tried to reboot
under 2.6.39, 2.6.38 and even 2.6.32 and the problem was still
present. Each time, unloading the module would fix the problem, but
loading it again wouldn't make the interface reappear. People
advised to boot with pcie_ports=compat but that didn't do anything.
I tried to boot without intel_iommu=force (disable Intel Vt-d) and
pcie_aspm (Active State Power Management) but nothing either.
Considering a userland issue, I've tried to boot a grml live distro (always keep a grml.iso in
your /boot, extlinux-update will even put it in your menu
automatically), and the problem was still present. So not a Debian
kernel issue, not a userland issue, only thing left was the laptop.
I didn't update the Bios recently, so I wondered exactly what could
be the problem. I started to feel a little bad, since I still
really like that laptop, and that I already decided to lend it to
my sister since her own T61 is sitting with a dead system board in
my shelf. I know she might have some negative waves, but she was
not even landed when the problem first appear.
The fix
Then I had a flash. It's not mystery that I'm used to break network
cards, and I had the bright idea to shutdown the laptop,
disconnect AC and battery, then let it idle a bit. I even tried the
secret Thinkpad power button code but I think it's unrelated.
Then I re-plugged the battery, booted to grml and the issue was
gone. I rebooted on the standard Debian and the link was up,
network was working.
So what happenned?
The (tentative) explanation
My guess is that, somehow, the network card firmware has an
issue and choked on something (a network frame or an attack exactly
like the one we demonstrated on ASF firmware). In fact, no, I don't
think it's the e1000e firmware. My T61 comes with Intel vPro, which
includes AMT (Active Management Technology), a remote management
solution a bit like ASF but more advanced. As far as I know, AMT
firmware always runs, even when it's disabled, it's just completely
idle. Idle, but in this case I think it choked on something, and a
reboot isn't enough to restart the AMT firmware. But a real hard
reset without any power seems to do the trick.
What next?
Well, a part of me is pretty scared, but another is just bored.
I mean, we know about that, that's exactly the kind of issue we are
warning people of. I have no idea what exactly happened, and
there's no way I'll be able to reproduce that, but I'm pretty sure
it's something lying at a pretty low level in the platform, and
which can severely disable your workstation. Now if it happens
again I won't lose too much time on this.
TL;DR: helping other people
In case you came here because you searched on google terms like
kworker cpu usage , e1000e, interrupts, it might be a good idea to
first reboot on a live CD to eliminate installation issues, then
shutdown the laptop, remove the battery and let it few seconds
idle. This might be enough to reset something inside and fix the
situation.
<div id="viewerPlaceHolder" class="nonipad">
<script
type="text/javascript">
if ((navigator.userAgent.indexOf('iPad') != -1))
document.write('<link rel="stylesheet" type="text/css"
href="/etc/designs/intel/us/en/css/intel.iOS.css" media="screen"
/>');
</script> <script type="text/javascript">
//
</script>
function gvim()
desktop=$(xprop -root -notype -f _NET_CURRENT_DESKTOP 0c '$0+\n'
_NET_CURRENT_DESKTOP)
if [ "$#" -ge "1" ];
then
gvimargs="--remote-tab-silent"
fi
=gvim --servername $desktop $gvimargs $*
The xprop trick is a hackish way to stick one gvim window per
workspace, it might need to be adjusted if one has a two monitors
setup and want to be able to have one editor per monitor per
workspace.
Basically, that snippet checks if a gvim server already exists
with the current workspace name. If yes, it opens the file(s) in
it, if not it run a new gvim server and opens the file there.
It works more or less fine, but it has one problem: it fails
badly when one needs to give args to the gvim call. Those args are
usually placed *before* filenames, so in my case it won't work. One
way to fix this would be to loop on all the args, check if the arg
is an existing file, in case add it to $files. If not, add it to
$args, then call gvim with the correct order. Works, except when
you want to edit a new file, where you're back to point one.
All in all, it'd work, but it's not really a nice way to do it,
imho. So I'm calling for help, in case anyone has an idea about
that. Basically, is there a way to say to gvim always open files
in a remote server, run it if it's not already running using the
config file and not an argument (so I don't mess with the command
line). I do need the servername to be desktop specific though, so
it's still a difficulty.
NOTE: I know that emacs has some kind of remote server
habilities too, but I'm not sure how it works and if it'd be
possible to do that in emacs, and I'm not really an emacs user and
don't really intend to switch.
If you have any idea, feel free to comment (by mail), I might do
a later post when I have an enhanced solution.
=debian-x
mailbox.
Debian XSF News #1
mesa 7.9
was uploaded to experimental
by Julien Cristau.xserver-xorg-sun*
drivers to experimental
for us.mrconfig
file to ease downloading/updating all XSF packages,
thanks to the mr tool, and
some bits of documentation. I also
added the git URL
to the upstream repositories to debian/watch*
for all packages.DRI
, and unfortunately, I
haven t digged into mesa
yet, but thankfully we had some answers
from upstream there.xfonts-*
packages, prepared by Julien Cristau.x11-*
bundles as well. Why are we creating
bundles? Because there are many tiny applications, which (from the
distribution point of view) don t deserve their own package. For
example x11-apps
contains toys like xclock
, xeyes
, or
xlogo
.lib*
packages, plus pixman
. When there were no
fundamental changes (as in: no need for an shlibs
bump, which
could prevent some packages from migrating), those were uploaded to
unstable
, others went to experimental
.libx11
, from a stable
branch. The
2:1.3.3-4
version
has been unblocked for squeeze,
and brings support for
Compose O A
and for
Compose \ o /
.apple:badmap
and
apple:goodmap
options for macintosh
keyboards in
xkeyboard-configuration
(which produces the xkb-data
binary
package), thanks to a
bugreport from Yves-Alexis Perez;
it s been unblocked for squeeze as
well. If someone notices an inversion of those keys after the
upgrade, that s probably because one of those options was added at
some point, was ignored and unnoticed, and finally taken into
account. Depending on the case, it s sufficient to switch to the
other one, or to remove it entirely.experimental
.xserver-xorg-video-mga
user (Ferenc W gner), we were
able to extract and apply a patch from
launchpad s #292214
to fix the dual head
breakage. Since we haven t seen any complains since then, we ll
probably ask for an unblock for squeeze
.RC1
for
X11R7.6
and it d be nice to keep it that way, but that requires time/work.corsac@hidalgo: sudo sysctl -a grep
kernel.grsecurity.tpe
kernel.grsecurity.tpe = 1
kernel.grsecurity.tpe_gid = 500
kernel.grsecurity.tpe_invert = 1
kernel.grsecurity.tpe_restrict_all = 1
So what I need from there is to add my user to that group:
corsac@hidalgo: sudo addgroup --gid 500
grsec-tpe
Adding group grsec-tpe' (GID 500) ...
Done.
corsac@hidalgo: sudo adduser corsac grsec-tpe
Adding user corsac' to group grsec-tpe' ...
Adding user corsac to group grsec-tpe
Done.
That works fine for general usage (at the cost of less
protection for my user).
When trying to build stuff in pbuilder, the first problem I hit
was during dependencies installation:
[81903.221359] grsec: From 127.0.0.6: denied chmod
+s
of /home/corsac/debian/pbuilder/build/cow.8616/usr/local/share/sgml/stylesheet
by /home/corsac/debian/pbuilder/build/cow.8616/bin/chmod[chmod:10424]
uid/euid:0/0 gid/egid:0/0,
parent /home/corsac/debian/pbuilder/build/cow.8616/var/lib/dpkg/info/sgml-base.postinst[sgml-base.posti:10421]
uid/euid:0/0 gid/egid:0/0
grsec enforces some more protection when in a chroot,
and especially forbids some operations in there. So I add an
exception, using sysctl. For that, a convenient
/etc/sysctl.conf.d/grsec.conf will help:
# we need to do stuff in chroots for package
building
kernel.grsecurity.chroot_deny_chmod=0
# lock grsec sysctl
# kernel.grsecurity.grsec_lock=1
The last one is still in comment since I know I'll have to tune
further the sysctl.
With this, the build-deps install fine, but when starting the
build itself, it fails because I can't execute stuff inside
chroot, and especially not debian/rules:
Sep 20 19:43:24 hidalgo kernel: [87339.510137]
grsec: From 127.0.0.6: denied untrusted exec of
/home/corsac/debian/pbuilder/build/cow.26657/tmp/buildd/evolution-data-server-2.30.3/debian/rules
by
/home/corsac/debian/pbuilder/build/cow.26657/usr/bin/fakeroot-sysv[fakeroot:10916]
uid/euid:1234/1234 gid/egid:1234/1234,
parent
/home/corsac/debian/pbuilder/build/cow.26657/usr/bin/fakeroot-sysv[fakeroot:10895]
uid/euid:1234/1234 gid/egid:1234/1234
That's again because of TPE. Because, inside the
chroot, the pbuilder user (uid 1234) doesn't belong to the
grsec-tpe group (which doesn't even exist). So the correct
fix here is to create a 500 group inside the chroot, and add the
pbuilder user:
corsac@hidalgo: sudo cowbuilder --login
--save-after-login
-> Copying COW directory
[ ]
root@hidalgo:/# sudo addgroup --gid 500
grsec-tpe
Adding
group grsec-tpe' (GID 500) ...
Done.
root@hidalgo:/# sudo adduser pbuilder
grsec-tpe
Adding
user pbuilder' to group grsec-tpe' ...
Adding user pbuilder to group
grsec-tpe
Done.
Et voil
!
Next.